Pragmatic Software Configuration Management

W henever I start a new software project, I look at the infrastructure the team has in place for doing things like setting up a development workspace, building, doing version management, and so on—the things that belong to the larger topic known as software configuration management (SCM). I worry about these elements because, in a sense, I’m lazy. I want to direct my energies into producing code that works and is maintainable. When I have to spend a lot of manual effort dealing with infrastructure issues, I suspect that I’m not generating as much value for the organization as I would if I could focus more on the steps for writing code (this includes understanding requirements and testing). Workspace management, integration, and build are important developer tasks, but they shouldn’t require excess effort. Often an organization’s SCM mechanisms don’t help with the work of building software as much as they could. Either no mechanisms exist for doing common tasks or the processes to use those mechanisms are too complicated and become tasks in themselves. On a daily basis, developers shouldn’t notice SCM that much, and what they do notice, they should eagerly embrace because these things help them do their jobs. When developers don’t find SCM processes to be helpful, it’s often because the processes don’t serve the organization’s goals well. This tends to be due to two issues: first, basic SCM structures are lacking and, second, the structure doesn’t fit well into the development environment. In our book Software Configuration Management Patterns: Effective Teamwork (Addison-Wesley, 2003), Brad Appleton and I saw this as a perfect application for pattern languages (see the related sidebar). Here is a brief overview of the essential patterns for a basic, agile SCM environment.